2. 不管你是哪一端工程師，你都應該在功能開發完，交付之前，從使用者角度去操作一次功能，確定是否自己有做對。

聽起來好像廢話，但意外蠻多人做不到(???) 可能有人會說，啊這不就是QA嗎幹我屁事?

沒有，我不是在講QA，我是在講最基本的：

你確定你的功能真的有做對嗎?

幹這問題會不會聽起來很智障XD

但我就是有遇過，最後功能根本就沒有做對工程師，還把東西交出來XDDDDDDDD

狀況百百種，有可能是他誤會了規格，可能是他漏看了什麼東西，可能是工程師之間哪端沒有溝通好，或是各種光怪陸離的理由。

但不管怎樣，工程師都應該都有義務，開發完最終從使用者的角度至少去操作一次功能，確定這個功能你是有做對的，再把它交給我 (不要浪費大家的時間好ㄇ：D)

我要特別強調**「從最終使用者角度去操作一次」**的這句話，我知道工程師在開發的過程中，有時候有些進度會互卡，階段性的驗收只能用打API或假資料的方式去驗收，這些都沒關係，很正常，但最終交付之前，工程師都應該從最終使用者角度去操作一次，功能到底有沒有對。

比方說，我們開發一個系統，可能有五個前端頁面，有三個後台系統，交互影響功能和顯示，不管是哪一端哪一頁做完他自己的部分後，工程師應該都要去檢視使用者角度整個產品最終的顯示狀態，如果沒有正常運作，要去把問題找出來，這是很重要也很基本的負責任的態度。

有可能問題不是你的code，而是跟你對接的code，或是環境的問題，甚至版本/套件/大家用的外掛不同，誰誰誰沒有更新，這些全都是工程師要解決的問題，千萬不要忽略了這點，很細節但也很容易是專案最後爆炸的地方。

工程師不能雙手一攤跟我講，你的部分都有做但不知道為什麼最終沒跑出來，這他ㄇ就是句幹話，因為問題沒有被解決，阿你問我我問鬼? 我PM甚至沒有技術能力去釐清中間環節到底是誰出了錯，只能你們工程師去把問題找出來，這也是在團隊合作中工程師要有意識你應該要做的事，要從整個產品的的角度去查看最終功能是否正確。

因為我PM只看最終的成品

最終交付給客戶的東西是一個完整的產品，對方不會知道是前端的誰出包還是後端的誰出包，他只會知道：你們這個團隊出包，東西沒做對

大家要有意識，我們都在同一條船上，賣修害

通常在一個團隊中，常常出現的狀況是不是1+1=2，有時候是1+1<2 (但至少>1)，在磨合過程中有任何人被貼上能力封印咒我都不意外，當然以我的職責最棒的狀態就是將團隊調整到1+1>2，只是這件事其實很大一部分也會歸根與工程自己的合作意識到底有沒有足夠，有意識的訓練這塊真的很重要。

不要永遠當那個等人來找你討論的人

我一直很想要推廣你應該要當那個主動去找別人討論的人，因為毫無例外的被動的人都會最雖小，屢試不爽：D 但我真的不懂為什麼還是有一堆人這麼被動。

主動這件事做了對工程師只會有好處沒有壞處，信我真的啦(大笑)

因為當今天功能敲定、報價敲定，就是要找你進來做事情的時候，該做的功能跟規格PM都會很明確的列出來，報價寫了你要做什麼功能，哪些是我最後要驗收的，一手交錢一手交貨(?) 沒有任何模糊地帶，工程師根本沒有任何地方可以閃。

那在這個狀況下，其實主動出擊才是對工程師自己本身最好的不是嗎?

你可以主動先打造一個對自己而言舒服的開發環境跟過程，用你喜歡的技術要求夥伴配合你，先講先贏，何樂而不為呢

這跟本超爽ㄉ好嗎?

所以我真的搞不懂等人家來找你討論到底是什麼操作，我就是會提刀來找你要功能，阿你伸頭一刀縮頭也是一刀(亂用)，喬個讓自己舒服點的姿勢開發不是比較好嗎?(敲手心)

所以我真的非常大力推廣，既然都閃不掉了那就拿出點勇氣，主動出擊去找你的夥伴討論，對我PM來講，這個功能最後到底是你做了30%他做了70%，還是你做了90%他做了10%

I don’t fucking care. 我就只要那個功能可以跑就好：D

都講的這麼清楚，還不知道要從哪裡偷懶的人，後那你真的是慧根不夠，多吃點杏仁補補腦

今天先聊到這樣啦